Subject: Re: Open Item List for Release 1 DLSw Standard

From: Lakshman Garikapaty <[email-masked]>
Date: Tue, 7 Jun 94 06:47:25 PDT

Hi,

Ref: to recent discussion on control/data message lengths:

I think we should have the following as a general rule of thumb:

 - We will have Only ONE dataframe message (all data messages) and the rest 
   are all Control message (including XID and any new control messages that
   can come up).

>-       Please document that the x1D 'Wide Area Hello' message used by MPNP 1.2
>        is of infoframe length and does not have a control header.
>
   Should't this be considered as a control message and not as infoframe.
   (you will be adding few extra bytes)

   The algorithm to read data from the tcp pipe is 

   if message_type is  dataframe then message_len is message_len passed in
   the dls msg else message_len is control_message_len which is equal to 72

>> The second option is to add a new SSP header field to both control and
> >information headers called Message Header Length. This would allow
> >unrecognized SSP messages to be discarded and the next SSP header to
> >be read without difficulty.
  
  The current DLS msg already has at two places the message length. Even
though this message length describes the data after the control or data
msg. we can use this filed to send any new data that is associcated with
the control message that we may add in future. We do not need another 
field to do this. As an example when we exchange XIDs, we use the xid as
a control message but tag on the xid information at the end of control
message and fill the message length. Even though it is a control message
you are passing data around. Don't you think this logic will suffice for
varying length of control messages that may be added in the future.

 Lakshman.

---

From: Frank Bordonaro <[email-masked]>
Date: Tue, 7 Jun 94 10:23:01 PDT

> varying length of control messages that may be added in the future.

Lakshman,

I agree that what you suggest will work, but I don't thhink it is the
best solution. The best solution is a flexible one that allows us to
change the size of the headers as we discover ways to optimize the protocol
over time. Your suggestion would cause us to append extra header fields 
at the end of the existing headers. The control message header is already
72 bytes. How much overhead are you willing to tolerate? 

Instead of adding an extra field for the header length, why not change
the meaning of one of the 'message length' fields since it appears twice
in the control header? If the SSP protocol is going to scale well in 
large networks we need to be aware of the SSP header overhead. 

Frank Bordonaro